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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

It defines the functionality required for the support of packet services over High PErformance Radio Local Area 
Network Type 2 (HIPERLAN/2) [3]. Separate ETSI documents provide details on the system overview, data link 
control layer, radio link control sublayer, other convergence sublayers and conformance testing requirements for 
HIPERLAN/2. 

The Packet based Convergence Layer is split into two parts, a Common Part and a Service Specific Part. The Common 
Part describes the functionality for adapting variable length packets/frames to the fixed size data units used at the Data 
Link Control (DLC) layer while the Service Specific Part describes the functionality required to support a certain 
protocol, e.g. Ethernet or IP. It is envisioned that several, independent, Service Specific Convergence Sublayers (SSCS) 
will be defined in the future as market requirements develop. The SSCSs all use the services of the Common Part and 
the DLC. 

The present document is part 1 of a multi-part TS covering the Packet based Convergence Layer, as identified below: 

Part 1: "Common Part"; 

Part 2: "Ethernet Service Specific Convergence Sublayer". 
Further SSCSs will be added in the future. 
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Scope 



The present document is applicable to HIPERLAN/2 equipment supporting packet services, such as Ethernet, 
IEEE 1394 [5] or IP. 

The present document does only address the functionality required to transfer variable length packets/frames over the 
radio interface between an HIPERLAN/2 Access Point and Mobile Terminal. It does not address the requirements and 
technical characteristics for wired network interfaces at the Access Point and at the Mobile Terminal. 

The Packet based Convergence Layer consists of a Common Part, defined in this document, and a Service Specific Part 
which consists of several Service Specific Convergence Sublayers (SSCS). The SSCSs are defined in separate 
documents. The Service Specific Convergence Sublayers all use the services provided by the Common Part and the 
HIPERLAN/2 Data Link Control (DLC) layer. 

The task of the Common Part of the Packet based Convergence Layer is to adapt variable length packets/frames 
provided by the different Service Specific Convergence Sublayers to the fixed data unit size used in the HIPERLAN/2 
DLC layer. 

The present document does not address the requirements and technical characteristics for type approval and 
conformance testing. These are covered by separate documents. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] ETSI TS 101 761-1: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DLC) Layer; Part 1: Basic Data Transport Functions". 

[2] ETSI TS 101 761-2: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DLC) layer; Part 2: Radio Link Control Protocol Basic Functions". 

[3] ETSI TR 101 031 (V2.2): "Broadband Radio Access Networks (BRAN); High PErformance Radio 

Locals Area Network (HIPERLAN) Type 2; Requirements and architectures for wireless 
broadband access". 

[4] ITU-T Recommendation 1.363.5 (08/96): "B-ISDN ATM Adaptation Layer specification: Type 5 

AAL". 

[5] IEEE Std 1394 (1995): "Standard for a High Performance Serial Bus". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply. 

HIPERLAN/2: High PErformance Radio Local Area Network Type 2, a short-range wireless LAN providing 
broadband local access. Standardized by ETSI Project BRAN 

Maximum Transmission Unit (MTU): maximum packet size in octets that can be conveyed in one piece over a link 

Protocol Data Unit (PDU): data unit exchanged between entities at the same ISO layer 

Service Data Unit (SDU): data unit exchanged between adjacent ISO layers 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AAL ATM Adaptation Layer 

AP Access Point 

ATM Asynchronous Transfer Mode 

BRAN Broadband Radio Access Networks (Project) 

CEP Connection End Point 

CL Convergence Layer 

CPCS Common Part Convergence Sublayer 

C-SAP Control Service Access Point 

DLC Data Link Control 

DLCC DLC Connection 

DUC DLC User Connection 

ETSI European Telecommunications Standards Institute 

HIPERLAN/2 High Performance Radio Local Area Network Type 2 

H/2 see HIPERLAN/2 

IP Internet Protocol 

ISO International Standards Organisation 

LSB Least Significant Bit 

MAC Medium Access Control 

MIB Management Information Base 

MSB Most Significant Bit 

MT Mobile Terminal 

MTU Maximum Transmission Unit 

PAD Padding field 

PDU Protocol Data Unit 

RLC Radio Link Control 

SAP Service Access Point 

SAR Segmentation And Reassembly 

SDU Service Data Unit 

SNMP Simple Network Management Protocol 

SSCS Service Specific Convergence Sublayer 

TS Technical Specification 

U-SAP User Service Access Point 
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Convergence Layer architecture 



4.1 



General 



The Convergence Layer (CL) resides on top of the Data Link Control (DLC) layer. The task of the Convergence Layer 
is to adapt the service requirements of different Higher Layers to the services offered by the HIPERLAN/2 DLC layer. 

Two types of Convergence Layers can be distinguished, a Cell based Convergence Layer and a Packet based 
Convergence Layer (see figure 4.1). Further Convergence Layers may be specified in the future. The Cell based 
Convergence Layer offers services to Higher Layers that use the fixed size ATM cell as the transfer unit. 
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Figure 4.1 : HIPERLAN/2 Convergence Layers 

The Packet based Convergence Layer offers services to Higher Layers that use packets or frames of variable size or 
fixed size which exceed the ATM cell size. Typical examples of these are Ethernet and the Internet Protocol suite. The 
Packet based CL consists of two main parts, a Common Part and a Service Specific Part, which consists of several 
Service Specific Convergence Sublayers (SSCS). It is envisioned that several different Service Specific Convergence 
Sublayers will be specified by BRAN to meet the requirements of different Layer 2 and Layer 3 protocols. 

4.2 Packet based Convergence Layer architecture 
4.2.1 User plane architecture 

The Packet based CL exchanges packets/frames of variable size with Higher Layers and it exchanges data units of fixed 
size with the DLC. This conversion of packets with a variable size into data units with a fixed size and vice versa is a 
function common to all supported Higher Layers and thus this functionality is part of the Common Part. The user plane 
of the Common Part is further subdivided into the Common Part Convergence Sublayer (CPCS) and the Segmentation 
And Reassembly (SAR) sublayer (see figure 4.2). 
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Part 1 : Common Part 
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Figure 4.2: Packet based Convergence Layer - user plane 

The main functions of the Common Part Convergence Sublayer are: 

to add padding and additional information to the packets received from the SSCS and pass the resulting packets 
to the SAR; 

to remove and interpret padding and information added at the peer CPCS from packets received from the SAR 
and pass them up to the SSCS. 

The main functions of the Segmentation And Reassembly sublayer are: 

to segment the packets received from the CPCS into fixed size data units. These are then passed down to the 
DLC via the DLC User SAP (U-SAP); 

at the receiver, to copy the fixed size data units from the DLC into a reassembly buffer and pass the reassembled 
packet up to the CPCS. 

The task of the Service Specific Part is to map specific service requirements of Higher Layers to the service offered by 
the DLC Layer and to convert packets received from the Higher Layer to the format expected at the CPCS and vice 
versa. As the requirements differ according to the Higher Layer, several SSCSs, each responsible for one specific Higher 
Layer, will be developed. The SSCSs that are supported are advertised and chosen at initial association. 

4.2.2 Control plane architecture 

The Packet based Convergence Layer also includes control plane procedures. The tasks of these are (not exhaustive): 
Convergence Layer selection at association time; 
Higher Layer parameter transfer and negotiation; 
mapping of Higher Layer connection management procedures to the DLC. 
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The Convergence Layer control plane interacts with the Radio Resource Control, Association Control and DLC 
Connection Control functions of the DLC control plane, i.e. the Radio Link Control sublayer (RLC), (see figure 4.3). 
The control plane procedures are defined in the SSCS. The Common Part is transparent to the control plane. 
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Figure 4.3: Packet based Convergence Layer - control plane 

An SNMP Management Information Base (MIB) containing also Convergence Layer specific parameters for 
performance and fault monitoring and basic configuration will be defined in the HIPERLAN/2 Network Management 
specification TS 101 762 (see Bibliography). 



Common Part - User Plane 



5.1 



General 



While the previous clause provides an overview on the general Convergence Layer architecture and describes where the 
Common Part is located, the following clauses specify the user plane of the Common Part itself. 

The user plane procedures of the Common Part provides the capability to transfer a (variable length) CPCS-SDU over a 
DLC user connection between an HIPERLAN/2 Access Point and Mobile Terminals. 

Multiple instances of the Common Part, one for each DLC User Connection, may process the required segmentation and 
reassembly functionality for this service in parallel as the functional model in annex D shows. The segmentation and 
reassembly concept is to a great extent adopted from the functionality described in AAL5 [4]. The main difference is the 
relinquishment of a Cyclic Redundancy Check and that the Common Part only supports the message mode service. 

Annex B contains SDL diagrams showing the procedures of the Common Part. An overview on how data units flow 
through the Convergence Layer, how the different PDUs of the Convergence Layer are structured and the naming 
conventions used is shown in annex C. 
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5.2 Primitives (informative) 



The Common Part of the Packet based Convergence Layer exchanges service primitives with the Service Specific 
Convergence Sublayer (SSCS) and the DLC. 

NOTE: The primitives are defined only for the purpose of describing layer-to-layer and sublayer-to-sublayer 

interactions. These primitives are defined as an abstract list of parameters, and their concrete realization 
may vary between implementations. No formal testing of primitives is intended. The following primitive 
definitions have no normative significance. 

5.2.1 Primitive types 

Interface between sublayers 

Two different primitives may be used between different sublayers. To indicate the absence of a Service Access Point 
these primitives differ from the primitives commonly used between different layers: 

inv (invoke), for a higher layer to request service from a lower layer; 

sig (signal), for a layer providing service to notify the next higher layer of any specific service related activity. 

The defined types for each category of primitive are shown as a list in curly brackets. 

EXAMPLE: CPCSJJNITDATA {inv, sig} 

In this example, the defined types are invoke and signal. 

5.2.2 Parameter definitions 

Endpoint identifiers: some primitives contain an endpoint identifier. This identifier shall be used to distinguish 
primitives related to different protocol instances. As identifier, the DLC User Connection ID, which is the concatenation 
of a MAC_ID and DLCC_ID [1], shall be used. The coding of this identifier is a local matter and not defined in the 
present document. The identifier is defined as: 

- DLC User Connection ID (DUC_ID) 

Message unit: each piece of higher layer information that is included in the primitive is called a message unit. A series 
of one or more message units may be associated with each primitive where each separate unit is related to one 
information element in the corresponding lower layer message. The list of message units is derived from the message 
definitions by reference to the information elements that may contain information from or to the CL. 

5.3 Common Part Convergence Sublayer 

5.3.1 Interface to the Service Specific Convergence Sublayer 

The following primitive is used for the data transfer service: 
CPCSJJNITDATA {inv, sig} 

Table 5.1 



PARAMETER 


INV 


SIG 


DLC User Connection ID (DUC ID) 


A 


A 


Message units (possible elements) 
Interface Data (CPCS-SDU) 


A 


A 


NOTE: A = Always 
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Interface Data (ID) 

This parameter specifies the Interface Data unit exchanged between the CPCS and the SSCS entity. The Interface Data 
unit is an integral multiple of octets and corresponds to one CPCS-SDU. 

5.3.2 Interface to the Segmentation and Reassembly Sublayer 

The following primitive is used for the data transfer service: 
SARJJNITDATA {inv, sig} 

Table 5.2 



PARAMETER 


INV 


SIG 


DLC User Connection ID (DUC ID) 


A 


A 


Message units (possible elements) 
Interface Data (SAR-SDU) 


A 


A 


NOTE: A = Always 



Interface Data (ID) 

This parameter specifies the Interface Data unit exchanged between the SAR and the CPCS entity. The Interface Data is 
an integral multiple of 48 octets and corresponds to one SAR-SDU. 



5.3.3 Functionality 



5.3.3.1 



General 



The CPCS functions are performed per CPCS-PDU. The CPCS provides several functions in support of the CPCS 
service user. The CPCS-SDU is passed across the CPCS interface in exactly one data unit. This service provides the 
transport of a single CPCS-SDU in one CPCS-PDU. 

The functions implemented by the CPCS include: 

a) Preservation of CPCS-SDU 

This function provides the delineation and transparent transfer of CPCS-SDUs. 

b) Error detection and handling 

This function provides for the handling of CPCS-PDU corruption. Corrupted CPCS-PDUs are discarded. Examples 
of detected errors include received length and CPCS-PDU Length field mismatch including buffer overflow, and 
improperly formatted CPCS-PDUs. 

c) Padding 

A padding function provides for 48-octet alignment of the CPCS-PDU trailer. 



5.3.3.2 



Coding of the CPCS PDU 



The CPCS functions require a 4-octet CPCS-PDU trailer. The CPCS-PDU trailer shall always be located in the last 4 
octets of the last SAR-PDU (i.e. in the last segment) generated from the CPCS-PDU. A padding field shall provide for 
48-octet alignment of the CPCS-PDU. The trailer together with the padding field and the CPCS-PDU payload (which 
corresponds to the CPCS SDU) shall comprise the CPCS-PDU. The size and position of the fields of the CPCS-PDU are 
given in figure 5.1, see also annex A. 
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CPCS SDU 



CPCS PDU 



MSB 


Variable Length Payload 






1 - <MTU> octets 


I I I 


MSB 


PAD 


Trailer 



Y ' 


I 


Future use 


Length 



2 octets 



2 octets 



NOTE: The <MTU> is described in sublclause 5.3.5. 

Figure 5.1 : CPCS-PDU format 

CPCS-PDU payload 

The CPCS-PDU payload shall be used to carry the CPCS-SDU. This field shall be octet aligned and can range from 1 to 
<MTU> octets in length. 

Padding (PAD) field 

Between the end of the CPCS-PDU payload and the CPCS-PDU trailer, there shall be 0-47 unused octets. These unused 
octets are called the Padding (PAD) field; they shall be strictly used as filler octets and shall not convey any information. 
Any coding may be used. This padding field shall complement the CPCS-PDU (including CPCS-PDU payload, padding 
field and CPCS-PDU trailer) to an integral multiple of 48 octets. The function of the padding is shown in figure 5.2. 

Future use - 2 octets 

This field is reserved for future use and shall be coded as zero "0". 

Length field - 2 octets 

The Length field shall be used to encode the length of the CPCS-PDU payload field. The length shall be binary encoded 
as number of octets. The most significant bit of the most significant octet shall be transmitted first. 



No padding required 



47 (3+44) padding octets 



multiple of 48 octets 



-*H- 



48 octets 



I I I 



Payload 



I I I 



Trailer 



I I I I 



Payload 
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PAD 



PAD 
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Figure 5.2: Examples how to use the PAD field 

5.3.4 Procedures 
5.3.4.1 General 

The procedures defined in the following subclauses are symmetric. The description is valid for both the MT and AP. 
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5.3.4.2 Procedures at the sender 



Upon reception of CPCS_UNITDATA invoke primitive, the CPCS-PDU shall be constructed as described in 
subclause 5.3.3.2 and passed to the SAR sublayer in a SAR_UNITDATA invoke primitive. 

5.3.4.3 Procedures at the receiver 

The CPCS receiver maintains the following parameter: 

<Maximum Transmission Unit> 

This parameter indicates the maximum SDU size in octets that may be delivered to a CPCS user. At the receiver, the 
value of this parameter shall be compared to the length of each CPCS-SDU before it is delivered. Any CPCS-SDU that 
has a length greater than Maximum Transmission Unit shall be discarded. 

When the CPCS receiver receives a SAR_UNITDATA signal primitive from the SAR sublayer the following procedures 
are performed on the Interface Data (corresponds to one CPCS-PDU): 

1) The Length field of the CPCS-PDU trailer is used to determine the length of the PAD field (length of received 
CPCS-PDU minus four (4) and minus the content of the Length field). If the PAD field is longer than 47 octets or 
not enough data has been received, the CPCS-PDU shall be discarded. 

2) If the value of the Length field is zero (0), the CPCS-PDU shall be discarded. 

3) If the value of the Length field is higher than the value of the <Maximum Transmission Unit>, the CPCS-PDU shall 
be discarded. 

4) If the CPCS-PDU has not been discarded as a result of the previous checks, the receiver shall extract the Payload 
field (i.e. the CPCS-SDU) from the CPCS-PDU and deliver it to the CPCS user via a CPCSJJNITDATA signal 
primitive. 

5.3.5 Maximum Transmission Unit 

The used Maximum Transmission Unit (MTU) depends on the supported SSCS and is specified in the corresponding 
SSCS Technical Specification. The maximum value for the MTU is 65 535 octets. 

5.4 Segmentation and Reassembly 

5.4.1 Interface to the DLC 

The DLC User SAP is specified in the DLC Basic TS [1]. The Convergence Layer requires an in-sequence delivery data 
transfer service from the DLC. The format of the SAR-PDU (which corresponds to the DLC-SDU) is shown in 
figure 5.3. The SAR procedures require that SAR-PDUs generated from different SAR-SDUs (corresponds to CPCS- 
PDUs) are not mixed. 

5.4.2 Functionality 
5.4.2.1 General 

The SAR sublayer functions are performed on a SAR-PDU basis. The SAR sublayer accepts variable length SAR-SDUs 
that are integral multiples of 48 octets from the CPCS and generates SAR-PDUs containing 48 octets of SAR-SDU data 
plus fields containing CL Flags and CL Tag. 

The functions implemented by the SAR include: 

a) Preservation of SAR-SDU 

This function preserves the SAR-SDU by providing for an "end of SAR-SDU" indication. 
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5.4.2.2 



Coding of the SAR PDU 



The SAR functions require a 12-bit SAR-PDU header that consists of a CL-Tag field (8 bits) and a CL-Flags field (4 
bits). The SAR-PDU header together with the SAR-PDU payload shall comprise the SAR-PDU. The size and position 
of the fields of the SAR-PDU are given in figure 5.3, see also annex A. 

SAR SDL) (integral number of 48 octets, corresponds to a CPCS PDU) 
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Figure 5.3: The SAR process and coding of the SAR PDU 

Convergence Layer Tag (CL Tag) - 8 bits 

This field is not used in the Packet based Convergence Layer. It is reserved for future use and shall be coded as zero "0". 

Convergence Layer Flags (CL Flags) - 4 bits 

The SAR Stop bit shall be transmitted in bit 2 of the CL Flags field. All other bits (i.e. bits 1, 3 and 4) are reserved for 
future use and shall be coded as zero "0". 

SAR Payload - 48 octets 

The payload shall consist of a 48 octets segment generated from the SAR-SDU. 

5.4.3 Procedures 
5.4.3.1 General 

The procedures defined in the following subclauses are symmetric. The description is valid for both the MT and AP. 

NOTE: It is assumed that the SAR receiver contains a reassembly buffer for storing received segments. However, 
the actual implementation is out of the scope of this document. 
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5.4.3.2 Procedures at the sender 

The SAR sender shall perform the following procedures: 

1) Upon reception of a SAR_UNITDATA invoke primitive, the SAR sender shall start the segmentation process. If the 
Interface Data (i.e. the SAR-SDU) has a length of more than 48 octets, the SAR sender will generate more than one 
SAR-PDU. In all SAR-PDUs, the SAR-PDU payload field shall be filled with 48 octets of CPCS information. A 
header consisting of the CL-Tag field and the CL-Flags field shall be added in front of the SAR-PDU payload. 

2) The SAR sender shall set the SAR Stop bit in the CL-Flags field for the last SAR-PDU generated from the Interface 
Data to "1". In all other cases (i.e. when the DLC_UNITDATA request does not contain the last segment generated 
from the SAR-SDU), the SAR Stop bit shall be set to "0". The sender shall trigger a DLCJJNITDATA request 
primitive containing the resulting SAR-PDU (corresponds to a DLC-SDU) for each segment generated from the 
SAR-SDU. 

5.4.3.3 Procedures at the receiver 

The receiver maintains the following parameters: 
<Maximum Transmission Unit> 

This is the same parameter as used in the CPCS receiver, see subclause 5.3.5. 

<Reassembly timer> 

The support of a reassembly timer is optional. The value of the timer is out of the scope of this document. 

The SAR reciever shall perform the following procedures: 

1) Upon reception of a DLCJJNITDATA indication primitive, the 48-octet SAR-PDU payload (the last 48 octets of 
the Interface Data received in the primitive) shall be copied to the reassembly buffer. 

2) If the SAR Stop bit in the CL-Flags field is set to "0" and the received number of octets in the reassembly buffer is 
greater than the value of the parameter <Maximum Transmission Unit> plus 3, the receiver shall discard any 
information in the reassembly buffer. 

3) If the SAR Stop bit in the CL-Flags field is set to " 1 " (indicating that the SAR-PDU contains the last segment of a 
SAR-SDU) and the data has not been discarded, the data in the reassembly buffer shall be delivered to the CPCS 
via a SAR_UNITDATA signal primitive. Data that is delivered is removed from the reassembly buffer. 

If a reassembly timer is supported, the following procedures apply: 

4) When the SAR receiver receives a DLC_UNITDATA indication primitive from the DLC with the SAR Stop bit set 
to "0", the reassembly timer shall be (re)started. 

5) When the SAR receiver receives a DLC_UNITDATA indication primitive from the DLC with the SAR Stop bit set 
to "1", the reassembly timer shall be stopped 

6) If the timer expires, the SAR receiver shall discard any information in the reassembly buffer. 



Convergence Layer Version 



The Convergence Layer Version number is an 8-bit field used in the RLC [2]. This field is split into two 4-bit subfields. 
The four most significant bits (bits 5 to 8) identify the version of the Common Part and the four least significant bits 
(bits 1 to 4) identify the version of the SSCS. The Convergence Layer Version number shall be set according to the table 
below to indicate the support of this edition (version 1) of the Common Part. 



Bits 8765432 1 

000 1 xxxx 



Meaning 

Packet CL, Common Part version 1 
supported 



ETSI 



17 ETSI TS 101 493-1 V1.1.1 (2000-04) 



7 Common Part MIB 



The Management Information Base parameters for the Common Part of the Packet based Convergence Layer will be 
defined in the H/2 Network Management Technical Specification. These MIB parameters may be moved into this 
section in a future edition of the present document. 
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Annex A (normative): 
Coding of PDUs 



PDUs are transferred between the Common Part and the underlying protocol layer in units of octets, in ascending 
numerical octet order (i.e. octet 1, 2, ..., n-1, n), see figure A. 1 and A.2. 

When a field is contained within a single octet, the highest bit number (i.e. the bit labelled 8) represents the high order or 
most significant bit (MSB). 

In a multi-octet field the order (i.e. the significance) of bit values within each octet decreases as the octet number 
increases. 



MSB 



Bits 
5 4 



Payload (CPCS-SDU) 



1 Octets 

1 



LSB 



PADDING (PAD = 0-47 octets) 



L+1 



MSB 



Future use 



Length (L) 



Figure A.1:CPCS-PDU 



Figure A.2: SAR-PDU (corresponds to a DLC-SDU) 



LSB 



L+PAD 

L+PAD+1 

L+PAD+2 

L+PAD+3 

L+PAD+4 



MSB 
8 


7 6 


Bits 
5 4 


3 2 


LSB 
1 






CLTag 


CL Tag (cont.) 


MSB 


CL Flags 


LSB 


MSB 




Pay 


load 







LSB 



Octets 

1 

2 
3 
4 

49 
50 
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Annex B (informative): 
SDL diagrams 

B.1 CPCS sender 



Process CPCS sender 



in: 






i I 



IDLE 



CPCSJJNJJDATA.inv 
(CPCS_Slf 



set PAD 



lenc |th 



Length of PAD is 

47 - ((Length of CPCS_SDU + 3) mod 48) 



Length := 

i of CPCS 3DU 



SAR_UNITBATA.inv 
(ID) 



ID := CPCS_SDU + PAD + 
Future Use + Length 



IDLE 
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B.2 CPCS receiver 



Process CPCS receiver 



i(i; 



LA 



IDLE 



SAR_UNIX0ATA.sig 
(ID) 



TRUE 



FALSE 



TRUE 




'The ID corresponds to a CPCS_PDU" 
' (and to a SAR_SDU) 

The CPCS_PDU consists of: 
CPCS SDU(1 -MTU octets) 
PAD (0-47 octets) 
Future use (2 octets) 
Length (2 octets) 



<= (length of ID) - Length - 4 <= 47 



ract CPCS_S )U 
am CPCS PDJ 



CPCS_UNhDATA.sig 
(CPCS_SDU^ 



±- 



IDLE 
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B.3 SAR sender 



Process SAR sender 



1(1) 






IDLE 



SAR_UNITJ3ATA.inv 

(ID) 



SAR_Stop_Bit := 
Payload := 48 octets of ID 
starting at pointer 

CL_Tag := 

Bit 2 of CL_Flags := SAR_Stop_Bit 

DLC_SDU := CL_Tag + CL_Flags + Payload 




TRUE 



FALSE 



DLC_UNITDATA.req 
(DLC_SDUO 



DLC_UNlfl3ATA.req 
(DLC_SDUj/ 



pointer := 
pointer + 48 



IDLE 



count := 
count - 48 



SAR_Stop_Bit := 1 
Payload := 48 octets of ID 
starting at pointer 



CL_Tag := 
Bit 2 of CL_Flags 



SAR_Stop_Bit 
DLC_SDU := CL_Tag + CL_Flags + Payload 



ETSI 



22 



ETSI TS 101 493-1 V1.1.1 (2000-04) 



B.4 SAR receiver 



Process SAR receiver 



1(1) 






RAS timerc 



free 
rejassembly buff 



IDLE 



IDLE 



DLC_SDU consists of 
CL_Tag (8 bits) 
CL_Flags (4 bits) 
Payload (48 octets) 



DLC_UNITBATA.ind 
(DLC_SDS 




MC|RE_SEGMENTS 



DLCJJNITRATA.ind 
(DLC_SDU1 



to 



sppend PayloEd 
reassembly bi ffer 



MTU + 3 < received 
number of octets in 
reassembly buffer 




TRUE 



TRUE 



set RAS timer 



Jt 



FALSE 



MC|RE_SEGMENTS 



TRUE 



SARJJNI 

(ID) 



!~The ID corresponds to a SAR_SDU. 
H It consists of the contents of the 
reassembly buffer 

TA.sig 




RAStiKqer 
jpportets 

mum 



r=set RAS timer 



-*s- 



FALSE 



free 
rejassembly buffer 



IDLE 
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Annex C (informative): 
Data unit naming convention 



CL User SAP 



■<ZZZ^>- 



SSCS-SDU 



SSCS-PDU 



CPCS-SDU 



Payload 



CPCS-PDU 



SAR-SDU 



Tag 


Flags 


Payload 



SAR-PDU 



DLC User SAP 



DLC-SDU 



Trailer 



Segment 


Segment 




Segment 



o 

Q. 

o 



< 



Header 


DLC Payload 


Trailer 



DLC-PDU 



>. 

ro 
_i 
a> 
u 

c 

<D 
O) 

k. 

> 
C 

o 
o 

T3 

0) 
(/) 

ro 
^3 

j£ 
u 
ro 
a 



O 
o 



Figure C.1 : Data unit naming conventions for the Packet based Convergence Layer 
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Annex D (informative): 
Functional model 

D.1 Sender 



CL-CEP 



DLC-CEPs 

addressed by DUCJD 




CL User SAP 



o 
in 



CPCS UNITDATA.inv 



(f) 
O 

Q_ 

O 



SAR UNITDATA.inv 



DC 
< 
(f) 



DLCJJNITDATA.req 



O 



ir y 



DLC User SAP 



Figure D.1 : Functional model for the Packet based CL sender 
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D.2 Receiver 



CL-CEPs 



DLC-CEP 
addressed by D4JCJD 




CL User SAP 



ii ii 



C/D 
O 
CO 



CPCS_UNITDATA.sig a 



C/D 
O 
Q_ 
O 



SAR_UNITDATA.sig 



< 



DLC UNITDATA.ind 



o 



z ± 



DLC User SAP 



Figure D.2: Functional model for the Packet based CL receiver 
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